Skip to content

Conversation

jaydeluca
Copy link
Member

@jaydeluca jaydeluca commented Jan 31, 2025

Related to #7345

Related to #13031

Pivoting from doing a code attribute addition to instead just migrating to using AdviceScope since the resulting code attributes were not useful. If we can come up with some other solution for the code attributes I can do a followup.

@jaydeluca jaydeluca requested a review from a team as a code owner January 31, 2025 11:19
@trask
Copy link
Member

trask commented Jan 31, 2025

Is this the right approach?

👍

cc @SylvainJuge

Comment on lines 124 to 125
equalTo(CODE_NAMESPACE, "play.api.mvc.ActionBuilder$$anon$2"),
equalTo(CODE_FUNCTION, "apply"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion this is not useful. It points to framework code and is the same for all endpoints.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree with Lauri here, if the value is the same for all spans then it does not provide much value for the end-user as with it they can't guess which part of the application code is related to the span.

We will very likely have exactly the same kind of issues with Webflux or other reactive frameworks where the application code is provided through nested lambdas and can't be described with a dedicated class/method. For those cases, the "span identity" should be provided through other attributes for example HTTP verb, path or span name which allows the end-user to understand the link with application code.

If we capture this technical and implementation-specific information, do we have a way to make any good use of it ?

One example I could think of is if we attempt to correlate those attributes with another source of information like inferred spans or profiling, however for those the correlation would be implemented through trace and span ID rather than on those code-level attributes.

I think this example is really interesting from the perspective of semconv attributes clarification as there are at least two distinct use-cases for those attributes:

  • provide more information about a span for the end-user: we may recommend to capture information that is related to the application code rather than framework/library details
  • capture "technical information" in a structured way that could not be described otherwise: profiling, inferred spans, ...

Copy link
Contributor

@SylvainJuge SylvainJuge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, some suggestions for a few potential code improvements, mostly to move more code into AdviceScope and inline what is needed there.

@laurit
Copy link
Contributor

laurit commented Jul 15, 2025

I'd suggest the advice conversion work to be done in a different PR since the main problem with this PR is that the added code attribute isn't useful.

@jaydeluca jaydeluca force-pushed the add-code-attributes-play-mvc branch from 288ae9b to d3ab703 Compare July 15, 2025 19:33
@jaydeluca jaydeluca force-pushed the add-code-attributes-play-mvc branch from d3ab703 to ed566b9 Compare July 15, 2025 19:35
@jaydeluca jaydeluca changed the title Add code attributes to play mvc controller spans Update play mvc to use AdviceScope Jul 15, 2025
@jaydeluca
Copy link
Member Author

I'd suggest the advice conversion work to be done in a different PR since the main problem with this PR is that the added code attribute isn't useful.

I ended up just switching this PR to focus on the advice conversion. If it would be cleaner to close this one and open a fresh one, I'm happy to do that.

@SylvainJuge
Copy link
Contributor

I ended up just switching this PR to focus on the advice conversion. If it would be cleaner to close this one and open a fresh one, I'm happy to do that.

Good idea, the scope of this PR is limited to play-2.4, there is also play-2.6 instrumentation that needs to be migrated, but this can be done in a separate PR.

Copy link
Contributor

@SylvainJuge SylvainJuge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can inline and simplify the closeScope method.

}
scope.close();

actionScope.end(throwable, responseFuture, (Action<?>) thisAction, req);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

casting to (Action<?>) is a bit weird. What if you changed @Advice.This Object thisAction to @Advice.This Action<?> thisAction, would that work?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, yea that seems to work, thanks

@laurit
Copy link
Contributor

laurit commented Jul 17, 2025

there is a failure in play 2.6 tests https://scans.gradle.com/s/36fci3go5n3se

Context parentContext = currentContext();
if (!instrumenter().shouldStart(parentContext, null)) {
return;
public static class AdviceScope {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a failure in play 2.6 tests scans.gradle.com/s/36fci3go5n3se

Strangely I haven't been able to reproduce the test failure locally. I am still investigating.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @laurit !

@trask trask merged commit 2e4b962 into open-telemetry:main Jul 18, 2025
89 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants